fel: add FEL protocol and soc_info_t struct documentation - #241
Conversation
Add a markdown document describing the basics of the FEL protocol, to give some idea about the expectations and limitations of the protocol. Also add a description for each member of the soc_info_t struct, and explain how their values should be determined for a new SoC. Signed-off-by: Andre Przywara <osp@andrep.de>
dlan17
left a comment
dlan17
left a comment
There was a problem hiding this comment.
This doc is really excellent for people to get overview of soc_info structure, so I realize it's not really necessary to get into too many details which takes extra more efforts, or even we can just leave to improve them later.
| - `name`: A string with the short name of the SoC, like `"A133"` or `"T527"`. | ||
| - `spl_addr`: This is the address where the BootROM(BROM) will load an eGON | ||
| wrapped payload to. Often this is the start of the first SRAM block (SRAM A1), | ||
| though newer SoCs tend to deviate here. This must be the same value where the |
There was a problem hiding this comment.
for "must be the same value", it would be great to emphasis this choice is taken by sunxi-tools's policy for easing maintenance, not restricted by lowlevel BROM protocol, which I mean it's totally ok to download code to any valid address and execute..
There was a problem hiding this comment.
It's not OK to load the U-Boot's SPL to a wrong address because it's not position independent.
There was a problem hiding this comment.
I agree with @ssvb: it's essential to use the same address. Loading mainline U-Boot is the main feature of this tool, so we have to live with the restrictions. If you want to download and execute arbitrary code, you can always do so via the FEL primitives (write & exec), and then you can pick you own addresses. But for the spl command it's required to comply with mainline SPL restrictions.
| SPL binary to work with any load method. | ||
| The SRAM address(es) should be mentioned in the memory map of the manual, but | ||
| it's best to confirm this by loading a small code snippet from SD card and | ||
| printing the load address. |
There was a problem hiding this comment.
is there any public repo available for that small code which able to print the address? or docs recorded for this
(I remember you shared that when I add fel support for A733..)
There was a problem hiding this comment.
I wouldn't be aware anything out there. The simplest solution is probably just a few instructions: learn the load address via adr, write that value right behind the code, then go to FEL. Then you can scan the SRAM via FEL to find the code and the address written. Maybe I add this to the repo some day.
| out (set to `false`) for every other SoC. | ||
| - `mmu_tt_addr`: Address of some memory area to hold the page tables during | ||
| the FEL operation. Only needed on older SoCs that enable and require the | ||
| MMU during FEL operation. Can be left out (set to 0) for newer SoCs. |
There was a problem hiding this comment.
It's not needed on old SoCs either. But it provided significantly faster data transfer speed. See the detailed explanations in the following commit messages:
e4b3da2, a275b24, c32eeb8. And also the table at https://linux-sunxi.org/FEL/USBBoot#SoC_support_status
The difference between ~180KB/s and ~900KB/s, observed on H3 was gigantic from the practical point of view, considering the typical sizes of the linux kernel images.
There was a problem hiding this comment.
If you have a H3 you should maybe see if DMA works on it. I get nearly a 100x speed increase with that on H616 and ported the optimizations based on BROM dump analysis.
4 participants
Add a markdown document describing the basics of the FEL protocol, to give some idea about the expectations and limitations of the protocol.
Also add a description for each member of the soc_info_t struct, and explain how their values should be determined for a new SoC.